Skip to content

feat: add sink-parity agent skill - #1689

Open
dcoric wants to merge 3 commits into
finos:feat/postgresfrom
dcoric:feat/sink-parity-skill
Open

feat: add sink-parity agent skill#1689
dcoric wants to merge 3 commits into
finos:feat/postgresfrom
dcoric:feat/sink-parity-skill

Conversation

@dcoric

@dcoric dcoric commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Adds a sink-parity skill for AI agents working on the sink backends.

The skill encodes the parity contract between src/db/file, src/db/mongo and src/db/postgres: the Sink interface in src/db/types.ts as the single source of truth, step-by-step checklists for adding interface members, entity fields and postgres schema changes, the semantic rules the compiler cannot enforce (defaults, timestamp bumps, projections, case handling, error behaviour), and the verification commands that catch drift.

It is written for any agent that reads AGENTS.md: Claude picks it up through the existing .claude/skills symlink and opencode through the added command stub, following the same layout as the existing skills.

Targeted at the feat/postgres integration branch since the parity obligation becomes three-way once the PostgreSQL sink lands.

Resolves #1688

Adds a skill that encodes the cross-backend parity contract for the
fs, mongo and postgres sinks: the Sink interface as the source of
truth, checklists for new members, entity fields and schema changes,
the semantic parity rules the compiler cannot enforce, and the
verification commands. Exposed to Claude through the .claude/skills
symlink and to opencode through a command stub.
@dcoric
dcoric requested a review from a team as a code owner August 24, 2026 10:07

@jescalada jescalada left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a few suggestions for agent output quality 👍🏼

## Adding or changing a Sink member

1. Add the member to the `Sink` interface with a doc comment stating its semantics (ordering, case sensitivity, empty-result shape).
2. Implement it in `src/db/file`, `src/db/mongo`, and `src/db/postgres`. Use the mongo implementation as the reference for behaviour unless the doc comment says otherwise.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the assumption here that usually a Mongo implementation will be added first (and the others must be filled in)? I feel this could be misleading if the agent takes it too literally...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering about what the "source of truth" should even be... The Mongo implementation is by default the "official" one, but it doesn't mean it'll always be the one to use as a template, especially if new Postgres functionality is added.

npm run format:check
```

Postgres integration tests (`npm run test:integration:postgres`) need a reachable PostgreSQL database; CI runs them in the dedicated lane.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be good to add a small testing section too:

  • Explain how units vs integration tests are set up, and tell it to add both types for each adaptor
  • Tell it to make sure the operations performed in each test are identical across sinks (unless N/A)
  • Tell it to make sure the outputs of each test are identical across sinks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants